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FOREWARD 


The  State  Implementation  Guide  has  been  prepared  to  provide  State  Administrators  with 
information  defining  how  to  pursue  the  implementation  of  the  Surveillance  and  Utilization 
Review  Subsystem  (S/URS)  of  the  Medicaid  Management  Information  System  (MMIS) 
within  their  State.  This  document  was  produced  by  the  Health  Care  Financing 
Administration,  Bureau  of  Program  Operations,  Office  of  Methods  and  Systems,  Division 
of  Systems  Planning  and  Development,  Systems  Development  Branch,  Baltimore, 
Maryland.  Other  documents  include  a  revision  (1982)  of  the  S/URS  General  Systems 
Design  (GSD).  It  is  suggested  that  persons  not  familiar  with  that  document  review  it  prior 
to  reading  this  State  Implementation  Guide. 


i 


ACKNOWLEDGEMENTS 


The  Surveillance  and  Utilization  Review  Subsystem,  State  Implementation  Guide  was 
prepared  by  Mr.  Daniel  C.  Boyle,  Miss  Toian  Vaughn,  and  Mr.  Robert  G.  Young  of  the 
Division  of  Systems  Planning  and  Development,  Office  of  Methods  and  Systems,  Bureau  of 
Program  Operations,  Health  Care  Financing  Administration,  Department  of  Health  and 
Human  Services.  Staff  from  the  Systems  Development  Branch  commented  on  the  draft 
and  otherwise  assisted.  Mrs.  Deborah  Abshire  prepared  the  manuscript. 

Also,  acknowledged  are  the  contributions  of  Michael  McKenzie,  Deputy  Director,  Division 
of  Family  Services,  Missouri  Department  of  Social  Services,  in  conducting  the  June  1982, 
pilot  test  of  the  revised  General  Systems  Design  for  Surveillance  and  Utilization  Review. 


ii 


CONTENTS 


SECTION  PAGE 

I.  INTRODUCTION 

A.  Background  1-1 

B.  Purpose  of  the  Guide  1-2 

C.  Organization  of  the  Guide  1-2 

D.  Project  Funding  1-2 

II.  PROJECT  INITIATION 

A.  Initial  Investigation  II-l 

B.  Management  Commitment  II-l 

C.  User  Involvement  II-2 

D.  Project  Staffing  II-2 

E.  Preliminary  Project  Schedule  II-2 

F.  Project  Control  II-3 

G.  Project  Team  Orientation  II-3 

III.  REQUIREMENTS  ANALYSIS 

A.  Purpose  III-l 

B.  Design  Environment  III-l 

C.  State  General  Systems  Design  III-2 

D.  Program  Policies  III-2 

E.  Implementation  Planning  III-3 

IV.  DETAILED  DESIGN 

A.  Purpose  IV-1 

B.  System  Specifications  IV-1 

C.  Programming  Specifications  IV-1 

D.  Implementation  Plan  IV-1 

V.    SYSTEMS  DEVELOPMENT 

A.  Purpose  V-l 

B.  Computer  Programming  V-l 

C.  Development  of  Non-Automated  Procedures  V-l 

D.  User  Training  V-2 


iii 


SECTION  PAGE 


VI.     SYSTEM  INSTALLATION 


A.  Data  Conversion  VI-1 

B.  Installation  and  Monitoring  VI-1 

C.  System  Maintenance  VI-1 

D.  Evaluation  of  System  Performance  VI-2 

VII.  APPENDIX 

Exhibit  1.  Project  Team  Organization  VII-1 

Exhibit  2.  S/URS  Development  Network  VII-2 

Exhibit  3.  Project  Status  Summary  Form  VII-3 

Exhibit  4.  Task  Progress  Report  Form  VII-4 

Exhibit  5.  Decision  Information  Request  Form  VII-5 

Exhibit  6.  Test  Evaluation  Report  VII-6 

Exhibit  7.  Non-Automated  Process  Flow  VII-7 

Exhibit  8.  Change  Control  Sheet  VII-8 


iv 


SECTION  I 
INTRODUCTION 


4 


I.  INTRODUCTION 


A.  BACKGROUND 

The  Surveillance  and  Utilization  Review  Subsystem  (S/URS)  was  initially  designed  to  meet 
the  requirement  for  providing  both  patient  and  provider  profiles  for  program  management 
and  utilization  review  purposes.  The  subsystem  was  to  provide  information  to  assist  in 
assessment  of  the  level  and  quality  of  care  provided  to  Medicaid  beneficiaries  and  to 
facilitate  the  investigation  of  suspected  instances  of  fraud  and  abuse  by  program 
participants. 

First  version  implementation  efforts  by  States  and  private  contractors  consisted  primarily 
of  installations  of  a  detailed  design  derived  from  the  "Medicaid  Management  Information 
System,  General  Systems  Design  (MMIS-GSD),"  and  State  modifications  of  existing 
systems  which  had  been  approved  by  HCFA.  These  installations  provided  the  mechanism 
for  ensuring  increased  Federal  Financial  Participation  (FFP). 

Second  version  S/URS  implementations  included  a  major  change  to  parameter  control. 
Definitions  of  data  on  reports  could  be  changed  by  completing  and  entering  a  parameter 
control.  There  was  no  longer  a  need  for  a  programmer  to  intervene  and  alter  a  computer 
program.  These  design  changes  greatly  reduced  the  amount  of  "hard  coding11  in  the 
subsystem.  Responsibility  for  making  changes  to  the  reports  shifted  to  persons  using  the 
reports.  The  intent  was  to  permit  flexibility  in  content  of  the  reports,  to  reduce  the 
amount  of  data  processed,  and  to  lessen  the  users'  dependence  on  systems  support 
personnel. 

The  revised  S/URS  GSD,  in  terms  of  basic  requirements,  is  a  sophisticated  second  version 
design.  Design  options  include  a  Data  Base  Design  which  when  combined  with  on-line 
capability  produce  a  third  version  design.  Such  designs  focus  on  increased  data  processing 
efficiencies. 

The  principal  functions  performed  in  the  revised  S/URS  subsystem  (1982)  are  to: 

o    Develop  comprehensive  statistical  profiles  and  utilization  patterns  of  health  care 
delivery, 

o    Reveal  suspected   instances  of  fraud   &  abuse  by  individual  providers  and 
beneficiaries,  and 

o    Provide  information  indicating  the  existence  of  any  potential  defects  in  the 
level  of  care  or  quality  of  service  provided  under  the  Medicaid  program. 

States  installing  the  revised  S/URS  General  Systems  Design  (1982)  can  expect  increased 
flexibility,  fewer  exception  reports,  better  quality  reports,  easier  analysis  and  improved 
computer  support  of  the  investigation  process.  Data  can  be  produced  in  manageable 
amounts  and  more  readily  used.  Computer  and  data  processing  personnel  resources 
needed  to  support  S/URS  activity  will  be  reduced,  run  times  will  diminish,  and  there  will 
be  greater  confidence  in  the  validity  of  S/URS  data  and  reports. 
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As  a  further  step  toward  improving  the  S/URS  a  revised  GSD  was  developed.  The  GSD  of 
the  revised  S/URS  provides  a  foundation  upon  which  any  given  State  can  build  a  S/URS  to 
satisfy  the  particular  requirements  of  that  State.  Since  there  is  considerable  variation  in 
the  implementation  of  S/URS  by  individual  States,  the  revised  GSD  stresses  flexibility  to 
meet  States'  needs.  It  has  not  been  tailored  to  fit  any  one  particular  State's  organization, 
policy,  or  approach  in  the  administration  of  the  Medicaid  Surveillance  and  Utilization 
Review  program. 

B.  PURPOSE  OF  THE  GUIDE 

This  publication  explains  in  general  terms  the  steps  that  a  State  needs  to  take  in  order  to 
translate  the  revised  General  Systems  Design  of  the  Surveillance  and  Utilization  Review 
Subsystem  of  the  Medicaid  Management  Information  System  (MMIS)  into  an  operational 
system  that  serves  individual  State  needs.  The  material  contained  in  this  Guide  is 
presented  with  the  assumption  that  the  reader  is  familiar  with  the  current  and  revised 
GSDs  and  the  MMIS. 

C.  ORGANIZATION  OF  THE  GUIDE 

As  far  as  possible,  the  activities  that  are  necessary  to  support  the  implementation  of  the 
S/URS  are  presented  in  chronological  order.  This  order  does  not  necessarily  imply  the 
relative  importance  attached  to  the  activities,  but  rather  presents  the  logical  sequence  of 
activity. 

The  sections  which  comprise  the  State  Implementation  Guide  are: 

I.  Introduction 

II.  Project  Initiation 

III.  Requirements  Analysis 

IV.  Detailed  Design 

V.  System  Development 

VI.  System  Installation 

D.  PROJECT  FUNDING 

If  the  revised  S/URS  GSD  is  developed  as  a  part  of  the  MMIS,  the  development  activities 
may  be  eligible  for  funding  with  90  percent  Federal  Financial  Participation  (FFP),  and 
operational  cost  may  be  funded  at  the  75  percent  level.  States  are  eligible  for  this 
special  funding  arrangement  because  S/URS  is  defined  as  a  subsystem  of  the  MMIS,  and 
because  it  provides  for  a  more  efficient,  effective,  and  economical  administration  of  the 
State  plan. 

o  States  that  have  a  certified  MMIS  (presently  receiving  75  percent  FFP  for 
operations)  may  apply  for  90  percent  FFP  for  development  of  a  revised  S/URS 
Management  Information  System. 
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o  States  already  in  the  process  of  developing  MMIS  capabilities  (Advanced  Planning 
Document  (APD)  approved  for  90  percent  funding)  can  modify  their  system  plans 
to  include  the  development  of  a  revised  S/URS  with  90  percent  FFP. 

o  Development  of  the  revised  S/URS  may  also  be  funded  through  normal  50 
percent  FFP. 

Details  concerning  the  procedures  for  qualifying  for  90  percent  or  75  percent  FFP  in 
developing  an  improved  Management  Information  System  can  be  found  in  the  Department 
of  Health  and  Human  Services  (DHHS),  State  Medicaid  Manual,  Part  11,  Section  11230. 

In  general,  the  regulation  requires  the  submission  of  an  APD  for  approval  by  DHHS  prior 
to  development  of  an  information  system  with  90  percent  or  75  percent  FFP.  If 
development  work  is  to  be  performed  by  someone  other  than  the  State  Medicaid  agency, 
competitive  bidding  is  required  and  the  Request  for  Proposal  and  the  selection  of  a 
contractor  must  also  be  approved  by  DHHS.  A  detailed  State  implementation  plan  is 
required  prior  to  the  start  of  the  systems  development  effort  whether  the  work  is  to  be 
performed  by  State  personnel  or  by  outside  contract. 
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PROJECT  INITIATION 


II.  PROJECT  INITIATION 


A.  INITIAL  INVESTIGATION 

A  State  prior  to  implementing  a  S/URS  should  first  review  the  1982  revised  GSD.  If  the 
concepts  appear  to  be  useful  to  the  State,  a  more  in-depth  analysis  should  be  made 
concluding  with  a  feasibility  study.  The  purpose  of  the  investigation  should  be  to  analyze 
State  requirements  and  determine  the  applicability  of  the  GSD  concepts  to  the  solution  of 
State  problems.  The  analysis  should  establish  the  objectives  and  scope  of  a  State's 
requirements  and  the  feasibility  of  the  system  to  satisfy  the  State  informational  needs. 
Such  analysis  must  be  carefully  done,  requires  considerable  effort,  and  is  crucial  to  the 
ultimate  success  of  any  subsequent  implementation.  It,  of  course,  does  not  necessarily 
commit  the  agency  to  follow  through  with  an  implementation.  Should  the  analysis 
indicate  that  the  revised  S/URS  fulfills  this  need,  then  further  investigation  and  analysis 
can  be  performed. 

Higher  level  or  incentive  FFP  is  available  for  S/URS  APD  proposals  as  provided  by  Section 
1903(a)(3)  of  the  Social  Security  Act.  The  State  initiates  the  APD  process  when  they 
prepare  and  submit  an  APD  in  accordance  with  42  CFR  Subpart  C  and  Part  11  of  the  State 
Medicaid  Manual. 

Upon  selection  of  a  contractor,  but  before  acceptance  of  a  bid,  the  State  must  submit  to 
DHHS  for  approval,  the  proposed  contract,  the  final  contending  proposals,  and  the  report 
of  the  selection  committee,  with  the  criteria  used  for  evaluation  of  the  bids.  After  these 
documents  have  been  reviewed  and  approved,  the  design  and  development  of  the  revised 
S/URS  can  begin  utilizing  90  percent  Federal  funds. 

B.  MANAGEMENT  COMMITMENT 

It  is  extremely  important  to  the  success  of  the  implementation  effort  that  top 
management  personnel  understand  the  implementation  process  and  are  committed  to 
making  available  the  resources  needed  for  implementation.  The  management 
commitment  need  not  be  total  at  the  initiation  of  the  project.  The  initial  commitment 
needs  only  to  cover  the  first  few  steps  of  the  implementation  process.  As  the 
implementation  proceeds,  more  detailed  data  will  be  available  concerning  costs,  benefits 
and  time  frames.  At  each  major  milestone  in  the  development  process,  top  management 
personnel  should  review  results  and  approve  or  disapprove  the  continuation  of  the  project. 
This  step-by-step  commitment  and  approval  process  will  be  discussed  more  fully  in  later 
sections  of  this  guide. 
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C.  USER  INVOLVEMENT 


In  addition  to  a  commitment  by  top  management,  all  users  of  the  system  should 
understand  the  need  for  the  system  and  participate  in  the  development  process.  One  way 
to  insure  user  involvement  is  through  a  Project  Steering  Committee  which  would  contain 
members  from  all  user  organizations.  This  committee  would  review  project  reports 
produced  at  major  milestones  in  the  development  process.  The  committee  can  insure  that 
decisions  made  by  the  project  team  are  acceptable  to  all  user  organizations.  The 
committee  may  also  be  given  the  authority  to  recommend  modifications  to  policies, 
regulations,  and  procedures  to  more  fully  support  the  concepts  and  objectives  of  the 
revised  S/URS. 

D.  PROJECT  STAFFING 

A  project  team  will  need  to  be  established  to  accomplish  the  various  implementation 
tasks.  A  typical  project  organization  would  include  systems  development  specialists  as 
well  as  user  personnel.  The  project  team  must  operate  under  a  formal  organizational 
structure  so  that  everyone  has  a  clear  understanding  of  who  is  responsible  for  exactly 
what  functions.  A  clearly  defined  structure  is  especially  important  when  an  outside 
contractor  is  participating  in  the  implementation  effort.  A  formal  structure  for  the 
implementation  effort  using  an  outside  contractor  is  shown  in  the  Appendix  as  Exhibit  1. 
The  project  managers  would  normally  work  full-time  on  the  project  but  other  members 
might  spend  part-time  or  full-time  on  the  project  depending  upon  their  particular  duties 
and  assignments. 

In  order  to  provide  necessary  support  to  the  formal  project  organization,  it  is  imperative 
that  the  directors  of  the  project  team  have  access  to  top  management  in  order  that 
necessary  decisions  are  made  in  a  timely  manner.  If  a  direct  line  of  communication  is  not 
available  to  top  management,  then  the  authority  to  make  such  decisions  must  be 
delegated  to  an  individual  who  is  available  on  a  day-to-day  basis.  Experience  has  shown 
that  only  top  management  or  its  specially  designated  representatives  empowered  with 
decision-making  authority  can  provide  assurance  of  quick  enough  action  to  permit  a 
complex  project  (such  as  the  development  and  implementation  of  the  revised  S/URS)  to 
proceed  at  a  reasonable  pace. 

E.  PRELIMINARY  PROJECT  SCHEDULE 

Before  beginning  any  major  implementation  activities,  a  comprehensive  project  plan 
should  be  developed  in  as  much  detail  as  possible.  This  preliminary  plan  will  be  modified 
and  expanded  as  the  project  progresses.  The  initial  plan  is  necessary,  however,  so  that  all 
project  team  members  will  understand  the  direction  of  the  entire  project  and  will  see  how 
their  individual  contributions  fit  into  the  total  effort. 
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All  activities  to  be  performed  during  the  implementation  should  be  listed  and  the  person 
responsible  for  each  activity  should  be  designated.  Next,  the  relationships  between  the 
activities  should  be  established.  Some  activities  cannot  commence  until  other  activities 
are  completed,  while  certain  activities  can  be  performed  concurrently.  The  relationships 
among  the  project  activities  can  be  shown  most  easily  by  a  bar  chart,  a  CPM  network,  or 
a  PERT  chart.  A  sample  CPM  network  for  the  preliminary  scheduling  of  the 
implementation  of  a  revised  S/UR5  is  shown  in  the  Appendix  as  Exhibit  2.  Target  dates 
and  major  reporting  and  approval  milestones  may  or  may  not  be  shown  on  this  preliminary 
project  schedule  but  would  certainly  appear  on  later  modifications. 

In  conjunction  with  the  preliminary  project  schedule,  an  initial  resource  allocation  plan 
should  be  developed.  The  resource  allocation  plan  should  show  the  estimated  manpower 
required  for  each  phase  of  the  implementation  project,  the  cost  of  that  manpower,  other 
resources  needed  (machines,  equipment,  forms,  etc.),  and  their  estimated  cost.  Some  of 
the  estimates  at  this  time  will  by  necessity  be  "ballpark"  estimates. 

F.  PROJECT  CONTROL 

After  development  of  the  preliminary  project  schedule,  a  formal  project  control 
mechanism  should  be  established  for  the  remainder  of  the  project.  This  project  plan 
should  include  a  periodic  reporting  of  progress  against  the  project  schedule.  Progress 
reporting  on  the  S/URS  development  effort  is  especially  necessary  because  of  the  typical 
involvement  on  such  a  project  of  so  many  individuals  and  organizations.  Routine  progress 
review  meetings  with  the  Project  Steering  Committee  and  executive  management  serve 
to  keep  them  aware  of  the  status  of  the  project  and  enable  management  to  focus  on  any 
crucial  problems.  A  monthly  project  status  summary  report  is  keyed  to  the 
implementation  plan  activities  and  forms  the  basis  for  periodic  status  reporting.  This 
report  focuses  attention  on  the  progress  toward  the  various  project  milestones  and  on  any 
problems  encountered  or  anticipated  in  the  future.  A  sample  project  status  summary 
form  is  shown  in  the  Appendix  as  Exhibit  3.  Progress  on  individual  project  tasks  can  be 
reported  to  the  project  manager  on  a  form  such  as  the  one  shown  in  Exhibit  4. 

The  major  function  of  project  control  is  to  insure  that  all  aspects  of  the  project  are 
proceeding  smoothly  and  at  an  acceptable  pace.  If  any  problems,  slowdowns,  new 
requirements,  or  other  factors  threaten  to  delay  the  project,  it  is  the  responsibility  of  the 
project  manager  to  devise  a  solution  or  to  force  a  decision  to  keep  the  project  from  being 
delayed.  Exhibit  5  shows  a  sample  form  which  could  be  used  to  assist  in  this  project 
control  function. 

G.  PROJECT  TEAM  ORIENTATION 

Preparatory  to  formally  initiating  project  activity,  the  project  organization  should  be 
finalized  and  project  reponsibilities  defined  for  all  personnel  involved.  An  orientation  for 
all  project  participants  should  be  conducted  to  discuss  the  preliminary  project  schedule,  to 
provide  appropriate  background  information  about  the  S/URS  program  and  the  revised 
S/URS  GSD,  answer  questions,  and  resolve  potential  conflicts.  Existing  S/URS  operations 
and  policies  should  be  explained  to  those  team  members  not  already  familiar  with  the 
existing  activities  in  the  State. 
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SECTION  III 
REQUIREMENTS  ANALYSIS 


III.  REQUIREMENTS  ANALYSIS 


A.  PURPOSE 

The  requirements  analysis  is  a  key  activity  in  a  successful  S/URS.  The  requirements 
analysis  examines  the  information  needs  of  a  State  S/URS  program  and  determines  how 
the  revised  S/URS  will  be  tailored  to  meet  the  State's  specific  needs.  Products  from  this 
phase  of  the  project  include  a  general  systems  design  for  the  State  subsystem, 
recommendations  for  policy  and  procedural  modifications,  and  a  more  detailed  version  of 
the  project  implementation  plan. 

B.  DESIGN  ENVIRONMENT 

The  first  item  in  the  requirements  analysis  process  is  an  analysis  of  the  existing 
Surveillance  and  Utilization  Review  program  in  the  State.  This  analysis  should  include  an 
examination  of  the  program  organizational  structure  (what  individuals  and  organizations 
are  included  and  what  they  do),  a  review  of  procedures  and  systems  (whether  automated 
or  not),  and  an  examination  of  forms,  reports,  and  data  items.  Data  volumes  and 
frequencies  should  also  be  reviewed.  Interactions  between  S/URS  staff  and  other  MMIS 
modules  should  be  examined  closely,  as  well  as  interactions  between  S/URS  staff  and 
those  concerned  with  other  forms  of  utilization  review. 

Once  it  has  been  determined  what  is  actually  going  on  in  the  S/URS  program,  the  focus 
turns  to  what  should  be  going  on.  The  purpose  of  implementing  a  S/URS  is  to  improve  the 
operation  and  management  of  the  State  S/URS  program.  The  installation  of  the  revised 
S/URS  system  may  result  in  changes  to  existing  policy,  procedures,  and  operations.  In 
tailoring  the  revised  S/URS  to  the  State's  program,  the  project  team  members  will  be 
more  concerned  with  how  an  activity  is  to  be  performed  when  the  new  system  is  installed 
than  how  it  is  performed  now. 

Typical  questions  to  be  answered  will  likely  include: 

o  How  does  S/URS  relate  to  other  forms  of  utilization  review;  prepayment  edits 
and  audits,  utilization  control,  drug  regimen  review,  PSROs,  section  17  units, 
etc.? 

o  What  statutory  or  regulatory  provisions  govern  S/URS?  Are  any  more  needed 
to  remedy  problems  discovered  during  the  S/URS  analysis  process? 

-  What  features  of  existing  S/URS  have  been  especially  useful  and  efficient? 
What  features  have  proven  troublesome? 

o  How  is  the  S/URS  unit  organized?  Are  any  near  term  organizational  changes 
expected? 

o  What  other  units  provide  or  receive  data  from  S/URS?  What  changes  would 
they  like? 

o         Are  there  alternative  ways  of  defining  "exceptional"  use  of  Medicaid  benefits? 
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o  What  features  of  S/URS,  beyond  the  basic,  are  needed?  Case  management? 
Sampling?  Etc. 

o         How  can  Federal  and  other  reporting  requirements  be  addressed? 

-  Will  billing  and  enrollment  forms  and  coding  structures  need  to  be  changed? 

o  Are  data  base  management  techniques  maximized  so  they  contribute  to  the 
reduction  of  time  required  to  access  data? 

o  Are  computer  hardware  and  software  optimized  to  produce  exception  and 
detail  reports  based  upon  parameters? 

o  Have  revisions  for  S/URS  user  instructions  been  considered?  Will  the  revisions 
enhance  user  interface  in  the  determining  parameters  and  report  selection? 
Will  the  instructions  be  clear  and  the  system  interface  friendly  to  the  user? 

The  number  of  different  utilization  review  entities  involved  in  the  S/URS  related  activity 
have  a  great  impact  on  the  design  of  the  State  S/URS  Management  Information  System. 
The  more  entities  involved,  the  more  interactions  there  are  and  the  greater  the  need  for 
data  sharing. 

C.  STATE  GENERAL  SYSTEMS  DESIGN 

The  general  systems  design  for  the  State  S/URS  is  the  major  vehicle  for  documenting 
what  the  improved  procedures  and  systems  will  be.  This  document  should  be  similar  in 
format  to  the  MMIS-GSD  and  will  define  the  scope  of  utilization  review  and  control 
efforts  that  will  be  made  by  the  State.  This  includes  defining  procedures,  systems 
components,  and  responsible  parties  determined  to  be  appropriate  for  meeting  that  State's 
particular  requirements.  Output  reports  and  input  forms  will  be  finalized  in  a  non- 
technical form  to  support  unique  State  information  requirements.  All  data  processing 
elements  and  data  bases  will  be  defined.  Interfaces  with  processing  systems  for  other 
assistance  programs  will  be  specified  in  detail. 

The  use  of  on-line  or  remote  batch  terminals  will  be  explained,  if  appropriate.  All  data 
entry  and  data  communication  methods  will  be  specified.  Data  base  handlers  and  special 
report  generation  software  requirements  will  be  specified.  Other  computer  hardware  and 
software  requirements  will  be  itemized  and  data  controls,  data  security,  and  data 
retention  will  be  addressed. 

D.  PROGRAM  POLICIES 

Development  of  the  revised  S/URS  may  indicate  the  need  for  a  change  in  State  policies, 
procedures,  and  regulations.  The  review  of  existing  program  operations  may  reveal 
obsolete  policies,  inconsistencies,  contradictions,  and  omissions.  In  any  event,  new 
policies  and  procedures  compatible  with  the  revised  S/URS  can  now  be  developed. 
Organizational  changes  also  may  be  desired  in  order  to  improve  the  mechanisms 
associated  with  S/URS  review  activities  and  paperwork  flow.  The  Project  Steering 
Committee  can  serve  as  a  useful  forum  for  discussing  policy  and  organizational  changes 
and  may  recommend  changes  to  policy  and/or  organizational  structure.  Documentation  of 
operations  or  proposed  policy,  and  of  implementation  is  essential. 
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E.  IMPLEMENTATION  PLANNING 


After  completion  of  the  G5D  of  the  revised  S/URS,  the  preliminary  project  plan  and 
schedule  should  be  updated.  At  this  point  more  information  will  be  known  about  the  scope 
and  complexity  of  the  system  so  that  accurate  estimates  can  be  made  of  time  frames, 
personnel  requirements,  and  costs.  Detail  can  be  added  to  the  preliminary  plan  to 
elaborate  depiction  of  project  activity. 

Computer  hardware  and  software  requirements  will  be  known  at  this  time,  but  the 
selection  of  specific  hardware  and  software  components  will  not  have  been  made. 
Planning  activities  will  include  an  analysis  of  whether  current  State  resources  are  able  to 
meet  these  hardware  and  software  requirements,  and  if  not,  the  dates  by  which  new 
hardware  and  software  must  be  obtained  in  order  to  meet  the  implementation  schedule  of 
the  system.  Documentation  of  Automated  Data  Processing  (ADP)  changes,  including  all 
aspects  related  to  hardware,  software  and  data  bases,  is  essential. 
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IV.  DETAILED  DESIGN 


A.  PURPOSE 

The  purpose  of  the  detailed  design  is  to  translate  the  S/URS-GSD  to  a  form  that  enables 
computer  programmers  to  write  individual  programs  that  will  work  together  to  perform 
all  automated  systems  functions.  Whereas  the  GSD  is  conceptual  in  nature  and  user 
Griented,  the  detail  design  is  oriented  toward  computer  processes.  The  detailed  design  is 
normally  composed  of  three  parts,  the  systems  specifications,  the  program  specifications, 
and  a  detailed  implementation  plan. 

B.  SYSTEM  SPECIFICATIONS 

The  system  specifications  describe  how  operations  will  be  performed.  Processing 
requirements  normally  consist  of  program  linkage  flowcharts  which  show  the  activities  of 
individual  computer  programs  (modules)  and  the  linkage  between  individual  programs. 
Other  system  specifications  include  narratives,  reports,  layouts  of  a  technical  nature  (as 
opposed  to  conceptual  layout  in  the  GSD),  data  base  and  data  set  layouts,  input  layouts, 
and  data  coding  structures.  The  technical  system  specifications  may  also  include  a 
description  of  the  computer  operating  systems  and  the  programming  language  to  be  used 
as  well  as  data  base  software  and  other  supporting  software.  Parameter  functions  and 
programming  standards  should  be  defined;  if  any  questions  exist  about  the  installation 
standards,  they  should  be  resolved.  Specific  equipment  usage  and  requirements  are  to  be 
finalized  at  this  point.  Data  security  requirements  should  be  defined  and  data  archival 
methodology  adopted.  Data  controls  are  defined  and  backup  and  recovery  procedures  are 
documented. 

C.  PROGRAMMING  SPECIFICATIONS 

Each  individual  computer  program  (or  run  module)  within  the  system  should  be  individually 
documented.  The  result  is  a  set  of  detailed  specifications  from  which  the  computer 
programmer  can  proceed  with  little  or  no  further  outside  reference.  Each  program 
specification  should  include  a  statement  of  purpose  and  functions  of  the  program, 
narratives,  and/or  flowcharts  of  each  component,  output  layouts,  input  layouts,  (including 
parameters),  interface  data  base  layouts,  and  test  criteria.  Common  processing  routines 
are  used  by  many  programs  and  are  usually  defined  in  detail  only  once  and  are  shared  by 
many  programs.  Likewise,  data  base  definitions  are  generated  only  once  and  are  shared 
by  many  computer  programs  whether  special  data  base  software  is  used  or  not. 

D.  IMPLEMENTATION  PLAN 

At  this  point  the  revised  S/URS  should  be  detailed  in  final  form  so  that  a  final  revision  to 
the  implementation  plan  can  be  made.  The  final  plan  will  include  a  detailed  schedule  for 
program  development,  a  data  acquisition  plan,  and  a  detailed  test  plan.  The  installation 
of  the  new  system  can  now  be  shown  in  more  detail  and  a  pilot  test  or  a  parallel  test 
operation  with  the  existing  system  can  be  performed.  The  actual  operation  will  be  on  a 
time-phase  basis  for  installation  and  operation  of  the  systems  components. 
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The  completion  of  the  detailed  design  phase  of  the  system  development  effort  represents 
a  major  review  milestone.  The  new  system  has  now  been  defined  in  such  detail,  that  there 
should  be  no  questions  as  to  what  the  system  should  look  like  or  how  it  functions. 
Likewise,  the  cost  of  the  new  system,  the  implementation  time  frame,  and  future  system 
benefits  should  all  be  accurately  estimated.  Since  the  major  expenditures  are  yet  to 
come,  the  decision  to  terminate  the  project  at  this  point  would  only  involve  a  fraction  of 
the  total  implementation  cost.  However,  assuming  that  the  benefits  still  outweigh  the 
costs,  a  decision  to  continue  the  project  would  be  forthcoming;  and  the  system 
development  activities  would  then  begin. 
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V.  SYSTEMS  DEVELOPMENT 


A.  PURPOSE 

The  systems  development  activities  transform  functions  and  requirements  into  operational 
reality.  During  this  phase  of  implementation  effort,  computer  programs  are  developed, 
compiled,  tested,  and  implemented.  Manual  procedures  for  operational  use  will  be 
developed  and  made  operational  and  documented  for  use  by  data  processing  personnel, 
S/URS  operational  personnel,  and  management  personnel.  This  documentation  will  then 
be  a  major  source  to  train  staff  to  use  the  S/URS. 

B.  COMPUTER  PROGRAMMING 

Generally  the  computer  programming  effort  is  divided  into  three  segments;  program 
design,  program  coding,  and  program  testing.  Therefore,  the  computer  programmer  is 
building  a  product  to  be  delivered  to  the  user  for  review.  The  computer  programmer  will 
be  responsible  for  development  of  individual  program  documentation  to  support  his 
deliverable  product  to  the  user.  Also,  the  computer  programmer  will  be  responsible  for 
the  quality  and  effectiveness  of  his  product  in  seeing  that  it  adheres  to  specifications 
contained  in  the  detail  design  of  the  State  S/URS. 

In  addition  to  meeting  detail  design  specifications,  the  design  of  each  program  run  unit 
should  consider  other  programming  objectives.  The  logic  should  be  clear,  precise,  and 
straightforward.  Programming  maintenance  and  updating  should  be  easy  to  perform.  The 
programmer  may  have  to  evaluate  trade-off  among  competing  objectives,  for  example, 
easy  maintenance  versus  quick  execution  time.  The  coding  of  the  program  run  unit  is  a 
translation  of  the  detailed  design  specifications  into  computer  programmable  instructions. 
Program  documentation  should  include  the  latest  program  listing,  the  job  control  language 
(JCL)  list  to  execute  the  program,  and  a  program  operation  run  manual. 

Program  coding  must  be  followed  by  thorough  unit  testing  for  each  run  unit  and  integrated 
systems  testing  of  multiple  run  units. 

Testing  methods  should  give  a  thorough  trial  to  the  system  and  each  component  of  the 
system.  The  computer  system  must  handle  not  only  routine  processing  but  also  any 
exceptional  conditions  which  can  appear.  A  formalized  Test  Evaluation  Report  of  the 
type  shown  in  Exhibit  6  should  be  used  to  communicate  discrepancies  identified  and 
corrective  action  taken. 

C.  DEVELOPMENT  OF  NON-AUTOMATED  PROCEDURES 

Concurrent  to  computer  program  development,  other  team  members  can  develop  non- 
automated  procedures  to  complement  the  automated  procedures.  With  the  installation  of 
the  State  S/URS  some  clerical  job  functions  may  change.  In  general,  one  can  anticipate 
routine  clerical  and  service  functions  being  replaced  by  automation  with  the  installation 
of  the  revised  S/URS. 
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Procedures  also  will  need  to  be  written  to  support  the  use  of  computer  reports  by  State 
and  local  management  and  operational  personnel.  A  report  user's  guide  should  provide 
instruction  on  how  to  interpret  each  report,  indicating  how  the  data  was  compiled,  what 
data  is  important,  and  how  the  data  will  be  used.  The  report  should  also  indicate  which 
organizational  entity  is  to  receive  the  report.  Error  correction  procedures  are  another 
important  aspect  of  the  manual  process  as  are  data  entry  procedures  and  data  control 
procedures. 

These  followup  steps  need  to  be  taken  in  the  development  of  manual  procedures  to  support 
the  revised  S/URS. 

1.  Determine  the  operational  functions  necessary  to  support  the  data  processing 
activities. 

2.  Identify  program  procedures,  processing  steps,  paper  flow,  data  requirements, 
and  managerial  requirements  involved  with  each  function  (activity). 

3.  Develop  a  procedural  flow  for  sequencing  the  various  functions  (or  activities) 
taking  into  account  the  flow  of  data  among  various  organizational  entities,  per 
example  shown  in  exhibit  7. 

4.  Define  the  responsibilities  and  tasks  of  each  individual  involved  in  the 
S/URS  process. 

5.  Prepare  individual  job  description  and  procedures  for  intake  documents. 

6.  Compile  the  manual  systems  documentation  into  a  book  (or  books)  to  be  used 
for  documentation,  references,  and  training  purposes. 

D.    USER  TRAINING 

Much  of  the  success  of  a  revised  S/URS  will  depend  on  the  type  and  quality  of  training 
provided  users  and  system  support  personnel.  Training  is  crucial  so  that  the  many  user- 
controlled  features  are  properly  used  to  produce  high  quality  reports,  in  manageable 
volume,  with  reasonble  computer  run-times,  and  acceptable  costs  for  data  processing. 
Personnel  to  be  instructed  include  clerical,  analyst,  investigator,  medical  support,  data 
processing,  S/UR  management,  and  other  personnel  with  involvement  in  S/URS  activities. 

Executive  management  needs  to  be  briefed  about  the  concepts,  procedures,  system 
structures,  projected  benefits,  and  relationships  of  S/URS  to  other  sources  of  information. 
Executive  management  needs  to  know  indications  of  a  successful  S/URS  operation  and 
how  to  integrate  S/URS  data  with  management  data  available  from  other  sources.  The 
training  of  S/UR  management  personnel  will  emphasize  the  overall  structure  of  S/URS, 
the  anticipated  benefits  including  how  S/URS  supports  other  utilization  control  functions, 
the  decision-making  process,  and  management  and  planning  features  that  are  available. 
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First  line  supervisors  are  usually  responsible  for  one  functional  aspect  of  the  S/URS 
program.  They  need  to  understand  the  entire  system,  but  need  additional  training  in  the 
specific  aspects  of  their  functional  area.  Special  emphasis  should  be  given  to  the 
management  and  operational  reports  which  measure  the  program's  efficiency  and  pinpoint 
operational  problems  within  their  area  of  responsibility. 

Data  entry  personnel,  especially  those  with  control  file  responsibilities,  need  instructions 
about  data  format,  data  field  size,  and  data  controls.  They  need  to  know  input  and  report 
distribution  procedures.  Error  correction  clerks  need  training  in  correction  of  various 
types  of  errors  that  will  occur. 

The  training  of  S/URS  clerical,  analyst,  investigator,  and  medical  support  personnel  is 
aimed  at  equipping  them  with  a  detailed  working  knowledge  of  their  job  with  regard  to 
S/URS.    Training  should  include: 

o         General  concepts,  features,  and  the  overall  processing  flow  with  the  State's 


S/URS  program. 


o 


Knowledge  of  the  various  documents  and  forms  involved. 


o 


Data  specifications  which  will  be  entered  into  the  computer  system,  including 
the  application  and  determination  of  appropriate  codes. 


o 


Data  edits  within  the  computer  system  which  will  result  in  identification  of 
errors  that  will  need  correction. 


o 


Error  correction  procedures  and  data  control  functions. 


o 


Interpretation  and  response  requirements  for  all  system  outputs  in  their 
functional  area. 
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VI.  SYSTEM  INSTALLATION 


A.  DATA  CONVERSION 

Conversion  of  data  to  meet  the  requirements  of  the  revised  S/URS  should  not  be  a  large 
effort.  The  S/URS  information  should  already  exist  in  an  automated  form.  Data 
conversion  computer  programs  should  be  written  and  tested  at  the  same  time  as 
operational  computer  programs.  In  some  cases  the  conversion  program  may  be  the  same 
program  as  the  operational  program. 

The  data  not  already  computerized  will  have  to  be  coded  and  added  to  the  S/URS  data 
base.  Special  procedures  will  have  to  be  written  in  order  to  include  only  the  S/URS 
information  which  is  valid  and  has  a  potential  to  exist. 

B.  INSTALLATION  AND  MONITORING 

Actual  system  installation  can  probably  best  be  accomplished  on  a  phase-in  basis  and  may 
involve  parallel  operations  with  the  existing  system  or  a  pilot  operation.  Data  conversion 
activities  (if  required)  must  be  coordinated  with  the  start-up  of  the  system.  The  revised 
S/URS  system  must  be  integrated  with  the  operation  of  the  existing  MMIS.  Eventually 
S/URS  operations  will  be  controlled  by  the  new  system  process. 

An  essential  task  in  the  establishment  of  any  new  system  is  post-installation  system 
monitoring.  This  monitoring  activity  is  necessary  to  identify  and  correctly  respond  to  any 
operational  problem  encountered.  The  manual  portions  as  well  as  the  automated  portions 
of  the  system  should  be  monitored.  The  monitoring  activity  will  adjust  the  system  to  the 
point  where  an  efficient  routine  operation  exists.  Considerable  effort  will  initially  be 
consumed  in  monitoring  the  new  S/URS,  however,  this  effort  should  decrease  rapidly  as 
problems  are  solved  and  the  users  gain  more  experience  and  confidence  in  the  system. 

In  reviewing  systems  operations,  attention  should  be  given  to  the  validity  and  accuracy  of 
the  information  generated  by  the  system  to  support  S/URS  management  and  operational 
functions.  Each  organizational  unit  that  receives  and  makes  use  of  system  outputs  should 
be  reviewed  during  the  monitoring  period.  This  review  will  determine  if  there  are  any 
discrepancies  in  the  report  data  or  any  other  problems  with  reports.  Report  users  should 
be  questioned  to  determine  if  they  are  able  to  make  proper  use  of  the  information 
furnished. 

C.  SYSTEM  MAINTENANCE 

Even  before  the  new  information  system  is  operational,  requests  for  changes  and 
modifications  normally  will  be  received  by  the  project  team.  A  moratorium  on  changes  is 
usually  imposed  from  the  time  programming  begins  for  the  new  system  until  the  system  is 
operational.  Otherwise  the  development  effort  is  continually  experiencing  revised 
schedules,  manpower  requirements,  etc. 
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Making  minor  changes  to  an  operational  system  to  meet  requirements  that  occur  in  the 
normal  course  of  events  is  the  typical  situation  for  any  data  system.  Change  requests  are 
typically  the  result  of  a  newly  imposed  requirement,  or  a  change  in  existing  policy  or 
regulation.  A  formal  change  control  procedure  is  needed  to  handle  each  modification  that 
becomes  necessary.  A  sample  change  control  sheet  is  shown  in  Exhibit  8  in  the  Appendix. 

The  change  procedures  are  essentially  an  abbreviation  of  the  systems  development 
activity  listed  in  this  guide.  A  requirement  for  change  should  be  analyzed  and  a  system 
solution  developed.  After  approval  of  all  parties  involved,  the  necessary  modifications 
are  made  to  the  computer  programs  and  to  the  manual  procedures  affected.  The  change 
is  made  operational  only  after  all  testing  and  user  training  are  complete. 

D.  EVALUATION  OF  SYSTEM  PERFORMANCE 

At  some  predetermined  point  after  system  installation  (and  from  time  to  time  during  the 
life  of  the  system)  an  evaluation  of  system  performance  should  be  conducted  to  determine 
the  systems  effectiveness  in  meeting  the  originally  stated  objectives  and  requirements  of 
the  information  system.  Since  some  of  the  reports  are  only  produced  annually  and 
historical  data  is  built  up  during  the  operation  of  the  system,  a  minimum  of  one  year  of 
routine  operation  is  necessary  before  any  meaningful  judgments  can  be  made.  The  post- 
installation  evaluation  of  system  performance  should  include  an  examination  of: 

1.  Operating  characteristics—operating  time,  success  in  meeting  schedules,  error 
rates,  etc. 

2.  Cost  of  operating  and  maintaining  the  system. 

3.  Success   in   meeting    original  design   objectives,   taking   into  account  any 
subsequent  changes  in  the  user  environment. 

4.  Compatibility  of  the  system  with  other  operational  systems,  including  the 
ability  to  be  integrated  with  new  systems. 

5.  ,  Degree  to  which  the  system  takes  advantage  of  available  equipment  or 

software  capabilities. 

6.  Adequacy  of  controls  and  security  measures. 

The  primary  purpose  of  this  review  is  to  determine  the  effectiveness  of  personnel  and 
project  team  members  in  realizing  the  objectives  of  the  revised  S/URS  GSD.  A  secondary 
benefit  comes  from  knowledge  that  the  specified  procedures  are  being  followed  and  that 
useful  results  are  being  obtained  in  all  areas  where  the  information  system  is  operating. 
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EXHIBIT  7 


CHANGE  CONTROL  SHEET 


Date: 
Requestor: 


Description  or  Nature  of  Change: 


Reason  for  Change: 


Recommendation  for  Change  Implementation  Procedure: 


Decision  Needed  By: 


To  Be  Effective  By: 


Area  Impacted  By  Change 


Nature  of  Impact: 


Impact  Area  Comments 


Contact-Person  In  Area; 


Area  Acknowledgement  &  Date: 


Area  Impacted  By  Change 


Nature  of  Impact: 


Impact  Area  Comments: 


  Contact-Person  In  Area 

Area  Acknowledgement  &  Date; 


Area  Impacted  By  Change 


Nature  of  Impact: 


Impact  Area  Comments: 


  Contact-Person  In  Area 

Area  Acknowledgement  &  Date: 


Rejection  or 
Approval  Date: 


Project  Manager: 
Impacted  Area  Authorizations: 
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